home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1997 April / macformat-049.iso / mac / Shareware Plus / Developers / dropg++ / usr / include / vm / TODO < prev    next >
Encoding:
Text File  |  1997-02-20  |  5.9 KB  |  116 lines  |  [TEXT/R*ch]
  1. A random assortment of things that I have thought about from time to time.
  2. The biggie is:
  3.  
  4. 0. Merge the page and buffer caches.
  5.    This has been bandied about for a long time.  First need to decide
  6.    whether you use VFS routines to do pagein/pageout or VM routines to
  7.    do IO?  Lots of other things to worry about: mismatches in page/FS-block
  8.    sizes, how to balance their memory needs, how is anon memory represented,
  9.    how do you get file meta-data, etc.
  10.  
  11. or more modestly:
  12.  
  13. 1. Use the multi-page pager interface to implement clustered pageins.
  14.    Probably can't be as aggressive (w.r.t. cluster size) as in clustered
  15.    pageout.  Maybe keep some kind of window ala the vfs_cluster routine
  16.    or maybe always just be conservative.
  17.  
  18. 2. vm_object_page_clean() needs work.
  19.    For one, it uses a worst-case O(N**2) algorithm.  Since we might block
  20.    in the pageout routine, it has to start over again afterward as things
  21.    may have changed in the meantime.  Someone else actively writing pages
  22.    in the object could keep this routine going forever also.  Note that
  23.    just holding the object lock would be insufficient (even if it was safe)
  24.    since these locks compile away on non-MP machines (i.e. always).
  25.    Maybe we need an OBJ_BUSY flag to be check by anyone attempting to
  26.    insert, modify or delete pages in the object.  This routine should also
  27.    use clustering like vm_pageout to speed things along.
  28.  
  29. 3. Do aggressive swapout.
  30.    Right now the swapper just unwires the u-area allowing a process to be
  31.    paged into oblivion.  We could use vm_map_clean() to force a process out
  32.    in a hurry though this should probably only be done for "private" objects
  33.    (i.e. refcount == 1).
  34.  
  35. 4. Rethink sharing maps.
  36.    Right now they are used inconsistently: related (via fork) processes
  37.    sharing memory have one, unrelated (via mmap) processes don't.  Mach
  38.    eliminated these a while back, I'm not sure what the right thing to do
  39.    here is.
  40.  
  41. 5. Use fictitious pages in vm_fault.
  42.    Right now a real page is allocated in the top level object to prevent
  43.    other faults from simultaneously going down the shadow chain.  Later,
  44.    a second real page may be allocated.  Current Mach allocates a fictitious
  45.    page in the top object and replaces it with a real one as necessary.
  46.  
  47. 6. Improve the pageout daemon.
  48.    It suffers from the same problem the old (4.2 vintage?) BSD one did.
  49.    With large physical memories, cleaned pages may not be freed for a long
  50.    time.  In the meantime, the daemon will continue cleaning more pages in
  51.    an attempt to free memory.  This can lead to bursts of paging activity
  52.    and erratic levels in the free list.
  53.  
  54. 7. Nuke MAP_COPY.
  55.    It isn't true anyway.  You can still get data modified after the virtual
  56.    copy for pages that aren't present in memory at the time of the copy.
  57.    The only concern with getting rid of it is that exec uses it for mapping
  58.    the text of an executable (to deal with the modified text problem).
  59.    MAP_COPY could probably be fixed but I don't think it is worth it.  If
  60.    you want true copy semantics, use read().
  61.  
  62. 8. Try harder to collapse objects.
  63.    Can wind up with a lot of wasted swap space in needlessly long shadow
  64.    chains.  The problem is that you cannot collapse an object's backing
  65.    object if the first object has a pager.  Since all our pagers have
  66.    relatively inexpensive routines to determine if a pager object has a
  67.    particular page, we could do a better job.  Probably don't want to go
  68.    as far as bringing pages in from the backing object's pager just to move
  69.    them to the primary object.
  70.  
  71. 9. Implement madvise (Sun style).
  72.    MADV_RANDOM: don't do clustered pageins. (like now!)
  73.    MADV_SEQUENTIAL: in vm_fault, deactivate cached pages with lower
  74.     offsets than the desired page.  Also only do forward read-ahead.
  75.    MADV_WILLNEED: vm_fault the range, maybe deactivate to avoid conspicuous
  76.     consumption.
  77.    MADV_DONTNEED: clean and free the range.  Is this identical to msync
  78.     with MS_INVALIDATE?
  79.  
  80. 10. Machine dependent hook for virtual memory allocation.
  81.    When the system gets to chose where something is placed in an address
  82.    space, it should call a pmap routine to choose a desired location.
  83.    This is useful for virtually-indexed cache machine where there are magic
  84.    alignments that can prevent aliasing problems.
  85.  
  86. 11. Allow vnode pager to be the default pager.
  87.    Mostly interface (how to configure a swap file) and policy (what objects
  88.    are backed in which files) needed.
  89.  
  90. 12. Keep page/buffer caches coherent.
  91.    Assuming #0 is not done.  Right now, very little is done.  The VM does
  92.    track file size changes (vnode_pager_setsize) so that mapped accesses
  93.    to truncated files give the correct response (SIGBUS).  It also purges
  94.    unmapped cached objects whenever the corresponding file is changed
  95.    (vnode_pager_uncache) but it doesn't maintain coherency of mapped objects
  96.    that are changed via read/write (or visa-versa).  Reasonable explicit
  97.    coherency can be maintained with msync but that is pretty feeble.
  98.  
  99. 13. Properly handle sharing in the presence of wired pages.
  100.    Right now it is possible to remove wired pages via pmap_page_protect.
  101.    This has become an issue with the addition of the mlock() call which allows
  102.    the situation where there are multiple mappings for a phys page and one or
  103.    more of them are wired.  It is then possible that pmap_page_protect() with
  104.    VM_PROT_NONE will be invoked.  Most implementations will go ahead and
  105.    remove the wired mapping along with all other mappings, violating the
  106.    assumption of wired-ness and potentially causing a panic later on when
  107.    an attempt is made to unwire the page and the mapping doesn't exist.
  108.    A work around of not removing wired mappings in pmap_page_protect is
  109.    implemented in the hp300 pmap but leads to a condition that may be just
  110.    as bad, "detached mappings" that exist at the pmap level but are unknown
  111.    to the higher level VM.
  112. ----
  113. Mike Hibler
  114. University of Utah CSS group
  115. mike@cs.utah.edu
  116.